Add export filter by inputtag #86
Conversation
… maps to first file in list (=default no tag export)
|
Hi @Paul-Blanchaert BR |
|
Hi Dominic,
The PR is taking an inputtag property from config (environment var) and
splits the export to generate a rewriter rules file per inputtag value
(incl. a rewriter rule file for missing tag)
…------------------------------
Kind regards,
Paul Blanchaert <https://www.search-solutions.net/p/paul>
www.search-solutions.net
Tel: +32 497 05.01.03
[image: View my profile on LinkedIn]
<http://be.linkedin.com/in/paulblanchaert>view
<http://be.linkedin.com/in/paulblanchaert> or connect
<https://www.linkedin.com/inviteFromProfile?from=profile&key=682342&firstName=Paul&lastName=Blanchaert>
------------------------------
Please consider the environment before printing this e-mail.
This message is explicitly subject to the conditions of the e-mail
disclaimer, available via the following link: mail-disclaimer
<https://www.search-solutions.net/mail-disclaimer>. If you are unable to
consult this e-mail disclaimer, please notify the sender at once.
On Thu, 25 Nov 2021 at 22:42, dobestler ***@***.***> wrote:
Hi @Paul-Blanchaert <https://github.com/Paul-Blanchaert>
Does your PR enable the export of rules having set certain inputtag(s) via
REST interface? Sorry, I was too lazy to properly look at your changes. I
am asking because I wanted to extend the REST endpoint GET
/api/v1/allRulesTxtFiles to take a list of inputtags to only export the
rules with these inputtags.
BR
Dominic
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#86 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AB7M2CTDIBAVCUFQZLLAIR3UN2UVHANCNFSM5IWBFXZQ>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
|
|
Hi @dobestler, As for your question re the REST endpoint GET /api/v1/allRulesTxtFiles: the current version of the pull request will result in a zip file with all files being split per value of the configured inputtag property (e.g. for inputtag property = tenant, this would be: common_rules.txt (=rules without inputtag tennant), common_rules_AA.txt (=rules with inputtag tennant=AA), common_rules_BB.txt (=rules with inputtag tennant=BB), ...)). |
|
What is left for this PR to be merged? I am interested in this functionality |
... ? |
|
When I look at the commits on querqy/smui in 2022, they are all commited by mkr it seems |
|
Top! |
|
I would like to move this forward and I can offer help as well. @Paul-Blanchaert Maybe you could rebase to come a step closer? Feature question: Do you think it might be a bit clearer if the input tag is part of a new endpoint like @pbartusch What's your opinion? |
|
I am lacking context for the use case and the SMUI version that is running (OSC branch vs. SMUI-main), but I am fine with additional API features under the same version (v1) as long as they are backwards compatible. |
|
Thank you, I'm happy to push this through but can we please first
|
|
The goal of the change is to export smui rules by inputtag. This change basically allows to export the SMUI rules in different querqy rewriter files based on an input tag value. This "flexible" assignment of smui rules to different querqy rewriters can be useful for e.g. A/B testing of SMUI rules. The branch "add_export_filter_by_inputtag" in the o19s fork contains the code to export different files for a predefined (via env var) inputtag (e.g. inputtag “tenant”). When that configuration is set, the export behavior would change: instead of generating 1 rewriter txt file, it would create 1 rewriter txt file per “tenant” code (e.g. “common_rules_A” with rules with inputtag “tenant” = “A”, “common_rules_B” with rules with inputtag “tenant” = “B”, ...) An additional change by dobestler is to allow to export based on the inputtag that is provided in the REST request rather than via env var. That would be a cleaner and more flexible solution. A new endpoint like GET /api/v1/allRulesTxtFilesByTag/{tag} instead of the environment var would be nice... but should probably be extended with tagname and tagvalue: GET /api/v1/allRulesTxtFilesByTag/{tagname}/{tagvalue} and cater for a way to export all tagvalues at once via GET /api/v1/allRulesTxtFilesByTag/{tagname} when tagvalue is absent. Unfortunately, I don't have the time to work on SMUI, so I can't help to get this in a cleaner state now... When it would be helpful, I can always send a patch with the changes of the branch. |
|
I will close this PR under the following assumption: Goal of this export feature was to realize draft rules. For this exists another approach today ( #124 , #127 (comment) ) and another way forward with future versions ( #127 ). Feel free to re-open or add to this comment in case you have a different perspective or knowledge about other use cases that this feature would support. |
The goal of the change is to export smui rules by inputtag.
This change basically allows to export the SMUI rules in different querqy rewriter files based on an input tag value. This "flexible" assignment of smui rules to different querqy rewriters can be useful for e.g. A/B testing of SMUI rules.
The branch "add_export_filter_by_inputtag" in the o19s fork contains the code to export different files for a predefined (via env var) inputtag (e.g. inputtag “tenant”). When that configuration is set, the export behavior would change: instead of generating 1 rewriter txt file, it would create 1 rewriter txt file per “tenant” code (e.g. “common_rules_A” with rules with inputtag “tenant” = “A”, “common_rules_B” with rules with inputtag “tenant” = “B”, ...)
An additional change by dobestler is to allow to export based on the inputtag that is provided in the REST request rather than via env var. That would be a cleaner and more flexible solution. A new endpoint like GET /api/v1/allRulesTxtFilesByTag/{tag} instead of the environment var would be nice... but should probably be extended with tagname and tagvalue: GET /api/v1/allRulesTxtFilesByTag/{tagname}/{tagvalue} and cater for a way to export all tagvalues at once via GET /api/v1/allRulesTxtFilesByTag/{tagname} when tagvalue is absent.